Personal computer systems are well known in the art. They have attained widespread use for providing computer power to many segments of today's modern society. Personal computers (PCs) may be defined as a desktop, floor standing, or portable microcomputer that includes a system unit having one or more central processing units (CPUs) and associated volatile and non-volatile memory, including random access memory (RAM) and basic input/output system read only memory (BIOS ROM), a system monitor, a keyboard, one or more flexible diskette drives, a CD-ROM drive, a fixed disk storage drive (also known as a “hard drive”), a pointing device such as a mouse, and an optional network interface adapter. Examples of such personal computer systems are International Business Machine Corp.'s (IBM's) ThinkCentre™, ThinkPad™, Aptiva™, and IntelliStation™ series of personal computers.
PCs and other computer systems have also become increasingly connected by networks such as the Internet, intranets, Wide Area Networks (WANs), and Local Area Networks (LANs). Networks often use one or more protocols to facilitate communication between computers within the network and on other networks. Protocols such as the Internet Protocol (IP) and TCP are pre-established means of communication between computers on a network. IP allows for routing of packets of data (including both data and a header) from node to node, forwarding data packets based on a four byte destination address (the IP number). TCP creates a reliable communications stream on top of the somewhat unreliable packet IP (called TCP/IP when they are combined). TCP adds support to detect errors or lost data and to trigger retransmission until data is correctly and completely received. TCP treats data as a stream of bytes that includes a header that designates a starting byte and a size, allowing the receiver to detect missing or incorrectly sequenced packets.
Once a TCP connection is established, most transmissions ultimately result in a response (such as an ACK, or acknowledgement) from the receiver. Given the overheads associated with both TCP and IP, explicit acknowledgement of every transmission, however, could generate significant additional traffic. TCP therefore attempts to inject the fewest possible packets into the network to avoid congesting the network and adding load to routers and switches. A packet may be broken into multiple segments for ease of transmission. A “small” segment is any segment smaller than the Maximum Segment Size (MSS) negotiated by the sender and receiver when the TCP connection is established. The Nagle algorithm [described in Request for Comments (RFC) 896 of the Network Working Group entitled “Congestion Control in IP/TCP Internetworks”, Jan. 6th, 1984] is one mechanism used by TCP to reduce the number of acknowledgements transmitted over a network connection. The Nagle algorithm, when implemented, requires that a sender not have more than one unacknowledged small segment outstanding. When an unacknowledged small segment is outstanding, the sender holds any further data from an application until the outstanding segment is acknowledged by the receiver. TCP allows the receiver to possibly attach the acknowledgement to another response (a process also known as 'piggybacking'), eliminating the need for two transmissions and thus reducing the load on the network. When a TCP connection has primarily one-way communication, the opportunities for attaching the acknowledgement are limited. The Nagle algorithm thus often results in only one small segment being transmitted on a given connection per round trip time (RTT), which is the time it takes to transmit data and subsequently receive acknowledgement for that data, an undesirable delay in transmission in many instances.
The delays caused by the RTT when transmitting small segments are exacerbated by TCP's delayed acknowledgement policy. The traditional receiver TCP implementation delays sending an acknowledgement to a sender until it has data to send on the reverse path (allowing it to attach the ACK to the data), until it has at least two full-sized segments (2 times MSS bytes) to acknowledge, or until expiration of a delayed acknowledgement timer (typically about 200 milliseconds). When a sender transmits a small segment, the acknowledgement is typically not transmitted until expiration of the delayed acknowledgement timer, resulting in delays of hundreds of milliseconds on operations that should complete much faster and providing additional delays on top of the RTT time. Other delays are also possible because of the delayed acknowledgement timer, such as delays occurring in some operating systems (OS's) when a sender attempts to transmit a packet with a size larger than the OS network buffer size, which may result in one small segment remaining unacknowledged until expiration of the delayed acknowledgement timer.
The delay caused by the delayed acknowledgement time is particularly undesirable in situations with primarily one-way communication as acknowledgements of small segments will rarely be able to piggyback with other data. Because of the problems associated with the Nagle algorithm with some network connections, some application developers simply turn off the Nagle algorithm for a given network connection by using the TCP_NODELAY socket option. Additionally, system administrators on some operating systems can turn off the Nagle algorithm using OS tuning parameters. While for some applications this improves performance, for many applications turning off the Nagle algorithm will lead to increased stress of the network, particularly when some senders on the network have faulty output buffer management. Simply turning off the Nagle algorithm does not provide a satisfactory solution to Nagle-induced slowdown as turning off the Nagle algorithm can often slow down the network more than the Nagle algorithm itself. Moreover, turning off the Nagle algorithm also results in the loss of the benefits provided by the Nagle algorithm.
Another problem with turning off the Nagle algorithm is that this solution requires a correct diagnosis of a Nagle-induced slowdown in the first place. Current operating systems do not recognize when slowdowns are the result of Nagle-induced delays. When a network slowdown occurs, an administrator may not know what is causing the slowdown without having to analyze logs or to perform trace analysis. Even when a network slowdown can be improved by turning off the Nagle algorithm, administrators cannot determine quickly that this solution will provide a benefit, resulting in it being often ignored.
There is, therefore, a need for an effective mechanism for detecting and managing the use of the Nagle algorithm in TCP networks, particularly when those networks are susceptible to Nagle-induced slowdowns. There is an even greater need for such a mechanism when applications are inefficient in their transmission of data packets.